Some forms of malicious software (a.k.a., “Malware”) may attack computing devices to access personal information, account numbers, etc. For example, malware such as “user-mode rootkits” (e.g., “ZBot,” “SpyEye,” etc.) may inject malicious code into various ring 3 processes (e.g., user-level security processes having the fewest privileges) that “hook” system application programming interfaces (APIs) that are called by the process. “Hooking” replaces addresses in the import address table (IAT) of the process or in the export address table (EAT) of a shared object (SO), dynamically linked library (DLL), etc. with addresses corresponding to code that is not the intended target of the call. To carry out these operations, malware routinely call certain debug/system APIs. The debug/system APIs provide information to the malware allowing for hooks to be installed. The malware may then simply hide and act as a “man-in-the-middle” by receiving and then passing through calls from various processes, all the while listening for personal information that may be provided to other users for possible illegal or fraudulent uses.
Security software (e.g., anti-malware software) may employ a similar technique to defeat malware. The security software may hook debug/system APIs commonly called by malware to provide a safeguard against their being accessed for improper use. More specifically, the security software may initially be called in place of the debug/system APIs, may determine whether the calling process is malware, and may prevent the debug/system APIs from being accessed if the call is determined to be invalid. This protection solution remains effective as long there is no manner in which to circumvent or compromise the security software. However, security software may be constructed utilizing the same programmatic principals as the software it is meant to protect, and thus, may be vulnerable to infiltration by similar rootkit attacks. As a result, a significant weakness is introduced into the ability of the security software to protect the computing device.
Although the following Detailed Description will proceed with reference being made to illustrative embodiments, many alternatives, modifications and variations thereof will be apparent to those skilled in the art.